Thank you very much for this very useful PR.

Now my ideas on it:

1. @emillindq Already provided solution and test with ST's driver fix. My suggestion here would be push it anyway, cause it does only __DSB() after writing eth descriptors and therefore should not have impact on ethernet throughput or driver performance.

2.@reloZid Very elegant fix from you here! But we can't just change linker scripts every time we need specific memory regions configuration. I think here we need memory reallocation and MPU configuration possibilities in DT

@gmarull @erwango @galak Now we seems to have proper solution for solide bug fix with future improvents for the whole Zephyr project. What do you think? Especially, what do you think about MPU configuration and data regions definition in DT?

Thanks for this draft, will be useful to trigger discussions on how to find a proper fix for this problem and also future similar requirements.

I see some other projects have a sort of MPU API, e.g. https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-stm32/soc.c

In Zephyr I think something similar can be done if using CONFIG_CPU_HAS_CUSTOM_FIXED_SOC_MPU_REGIONS (see NXP k6x/k8x for example) and provide a soc level MPU configuration. In this case, as ST recommends SRAM3 for I/O Ethernet/USB:

SRAM3 could be configured entirely for that purpose at soc level, and just provide DT definitions for sram3 together with linker scripts facilities so that Ethernet buffers can easily be placed there. I'm not sure if that's the best approach, though.

I'm not really familiar with Zephyr MPU implementation, it would be good to have input from maintainers @ioannisg @galak @MaureenHelm @stephanosio @carlocaione

We need a possibility to configure MPU and SRAM sections over DT or KConfig for Zephyr. And then we need a possibility to use configured SRAM sections in our code.

dev-review (Dec 3, 2020):

Suggestion to utilize CONFIG_NOCACHE_MEMORY and look at adding one more section for the SRAM specific case in arch/arm/core/aarch32/cortex_m/mpu/arm_core_mpu.c.

@ioannisg would like to see over time cleaning up of the linker script and mpu tables to move into SoC specific code.

dev-review (Dec 3, 2020):

Suggestion to utilize CONFIG_NOCACHE_MEMORY and look at adding one more section for the SRAM specific case in arch/arm/core/aarch32/cortex_m/mpu/arm_core_mpu.c.

I would prefer not to add half-solutions. We can better define amount of work and split it here, providing proper and solid solution.

My idea is to add mpu_attributes section to each sram section. Something like this for h74x:

sram3: memory@30000000 {
		reg = <0x30000000 DT_SIZE_K(128)>;
		compatible = "mmio-sram";
                mpu_config {
                    attr = NOCACHE && SHAREABLE;
                };
	};

This needs changes in DT parser or at least an additional preprocessing step before original DT. In this preprocessing step west/zephyr specifig artifacts (like mpu_config) should be splitted from DT syntax and classing DT file should be generated. Additionally the MPU config should be saved and added after DT step to linker. Everything can be done inside of west or Zephyr specific west processing.

Any ideas to my proposal?

@ioannisg would like to see over time cleaning up of the linker script and mpu tables to move into SoC specific code.

The idea behind the changes is very good. But we need more scalable solution.

@Nukersson, this point was discussed during dev-review meeting. Of course this proposal lacks scalability. Though w/o alternative proposal we find it acceptable for now with few tweaks.
To define a more scalable alternative we'd need more variety of usage examples. A rework of the whole way to instantiate memory partitions from DT is something we'd like to get, but it has a lot of intrications so it was proposed to postpone post LTS (not before 6 monthes).

The idea behind the changes is very good. But we need more scalable solution.

@Nukersson, this point was discussed during dev-review meeting. Of course this proposal lacks scalability. Though w/o alternative proposal we find it acceptable for now with few tweaks.
To define a more scalable alternative we'd need more variety of usage examples. A rework of the whole way to instantiate memory partitions from DT is something we'd like to get, but it has a lot of intrications so it was proposed to postpone post LTS (not before 6 monthes).

Okay. I understand it. But then we need to plan proper solution within the roadmap for next year or two.

@reloZid it might be interested for you to rebase on top of latest master, following the merge of #30530.
Also, please remove the initial commits, so we only have to review the last version of the proposed solution. This should help in the review process

@reloZid would you mind rebasing ?

@erwango Sorry for the late reaction. I rebased the changes.

@ioannisg can you have a new look ?